La sécurité informatique n’existe pas. Ou n’existe plus. Il fut un temps (lointain) où il était possible de rendre un système informatique à peu près sûr, mais ce temps-là a disparu, au gré de la complexification exponentielle de nos systèmes.
Quand on fait de la sûreté des systèmes (au sens large, pas seulement informatique, la sûreté est l’assurance qu’un système fait correctement ce qu’il doit faire, ce qui implique aussi de le faire en toute sécurité), on nous apprend très vite que la fiabilité globale d’un système est égale à celle du composant le plus faible : lorsque, dans une chaîne, un des maillons se brise, la chaîne ne remplit plus son rôle.
Tout au plus peut-on réutiliser les petits bouts encore intacts pour certains usages, mais certainement pas pour l’usage initial. Imaginez une chaîne servant à fermer une porte ou un grillage avec un cadenas de haute qualité. Si la chaîne se brise, et même si le cadenas est intact, la porte pourra être ouverte.
L’informatique contemporaine est un infâme « accumoncellement » de chaînes de plus en plus longues, composées de maillons de plus en plus fragiles, puisqu’étant eux-mêmes des chaînes complexes, etc. Au risque de passer pour un vieux con (je regrette le temps où on pouvait me traiter de jeune con), l’équivalent des premiers systèmes d’exploitation pouvaient tenir en quelques kilo-octets (si, si) et donc pouvaient quasiment être validés formellement (le Graal en sûreté informatique).
Comptez les lignes de codes pour Windows ou Linux : on navigue désormais sur des dizaines de millions de lignes. Pour un attaquant, il suffit d’une erreur, alors que le défenseur quant à lui n’a tout simplement pas droit à l’erreur : cette loi n’est encore une fois pas spécifique à l’informatique, mais la complexité croissante ne confine guère à l’optimisme.
De quoi en pousser certains à la technophobie pour lutter contre cette complexification à outrance... Oui, ça fait toujours bizarre d’entendre un spécialiste informatique dire qu’il est technophobe, n’est-ce pas Ferd ?
Plus sérieusement, faute de pouvoir prendre des mesures coercitives, douloureuses et autoritaires, il faut faire avec. Et c’est bien là tout le sujet : on ne sécurise pas un système informatique (au sens où on le rend sûr et inattaquable), car ça devient impossible. Non, on gère les risques liés à l’utilisation des systèmes informatiques.
Par ailleurs, le crime suit l’usage : plus l’informatique sert à des activités importantes ou ayant de la valeur, plus cela va intéresser les petits malins et les grands criminels. Nous voilà donc avec un cocktail explosif : des menaces à profusion (un monde plein de malfaisants) et des systèmes hypercomplexes (présentant des vulnérabilités).
Un soupçon d’ISO 27005 et de vocabulaire
Abonnez-vous pour tout dévorer et ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (27)
#1
Si un incendie a 5% de chance de survenir pendant l'année, en 20 ans, on n'a pas 100% de chance (soit une certitude). Sinon tous les immeubles brûleraient tous les 20 ans… L'immeuble a 95% de chance de ne pas brûler pendant l'année, et donc en 20 ans, il a 0,95^20 = 0,36 soit 36% de chance de ne pas brûler, donc 64% de probabilité de brûler en vingt ans.
#1.1
#1.2
#2
"accumoncellement" je crois accumulation est suffisant en soi.
#2.1
#3
Et encore j'ai l'impression que la liste est orientée infra.
Il manque les notions portées côté développement telles que le SAST, le SCA, le DAST, le Secret Scanning, etc.
#4
Pas vraiment aligné ici, ce n'est pas forcément un éditeur qui invente une catégorie, mais aussi le marché / les analystes (cf Gartner qui rationalise régulièrement les catégories). Et pas plus aligné sur le fait que de multiples catégories sont négatives ; on est sur des débats d'experts avec des solutions qui répondent à des besoins différents. On ne viendrait pas critiquer le Vidal parce qu'il référence toutes les molécules et leur contexte spécifique.
Petit troll du lundi, je doute que "Advanced Persistent Threat" soit une catégorie de solution de sécurité :]
On pourrait en parler longuement, mais ce n'est pas qu'un argument marketing, loin de là. Toute la partie UEBA déjà historique maintenant se base là-dessus, sans compter l'implémentation dans les technos (SIEM, XDR ...)
#4.1
#4.2
-Soit parce que le ratio faux positif / faux negatif était beaucoup trop important (donc ça prenait beaucoup de temps et d'argent de vérifier/corriger les alertes)
-Soit parce que ça laissait globalement passer la majorité des attaques, et que le tarif pour bloquer 15-20% des attaques était prohibitif pour le ROI de la solution.
Après j'avoue que mes lectures sur le sujet ont déjà quelques années mais je ne crois pas avoir vu de tests impressionnant de solution de ce type (on va dire qui dépasse au moins 50% des attaques détectés).
#4.3
#4.4
Après OK tu as construit ta whitelist via ML, mais ça reste profondément la même chose, et effectivement dans un monde fermé avec "peu" de log ça marche.
Historique des modifications :
Posté le 17/06/2024 à 17h51
Oui mais ça ça fonctionne déjà bien sans ML et AI puisque tu as déjà listé les opérations valides
Posté le 17/06/2024 à 17h52
Oui mais ça ça fonctionne déjà bien sans ML et AI puisque tu as déjà listé les opérations valides, donc c'est pas de l'heuristique, c'est juste une whitelist
#5
Ca c'est la théorie. Dans la pratique, la plupart des équipes sécu avec qui j'ai bossé c'est "non tu peux pas" sans proposer.
Ce qui est contre productif comme méthode de travail.
#5.1
#5.2
Les 3/4 du temps, les projets ne viennent pas avec un besoin mais une solution. Dans 90% des cas, foireuse, car ne prenant pas en compte le cadre d'architecture (le truc souvent dessiné sur un coin de table avec l'éditeur qui compte déjà les biftons).
Une fois ce filtre passé et le premier jet de proposition d'architecture fourni (sachant que je travaille en incluant la sécurité by design), je la traite avec l'équipe sécu. Et à chaque fois qu'il y a un truc qui va pas, c'est le même délire :
- ça c'est pas bon
- c'est quoi la préco ?
- de faire ça
- oui mais c'est quoi le standard ?
- il faut le faire
Dialogue de sourd. Et encore, j'ai ça parce que je propose des solutions (c'est mon métier en même temps). Mais à chaque fois il faut leur tirer les vers du nez.
Alors imagine les projets qui pratiquent le mensonge par omission en disant "non y'a pas de données confidentielles", "non c'est pas critique" mais que lorsque tu grattes (voire souffle dessus), la couche d'obfuscation saute et révèle qu'en fait, c'est la merde.
Mon plus gros reproche des travaux avec la sécurité dans mon expérience, c'est qu'elle se positionne de manière régalienne (ce qui est normal), mais ne propose jamais rien. Voire ne challenge pas suffisamment. C'est problématique car elle est vue comme une contrainte et non un moyen de protéger l'entreprise. Et ce genre de posture n'aide pas.
#5.3
#6
#6.1
#6.2
#6.3
#6.4
#7
"Ajouter des cloisons anti-feu, des systèmes de détection et de prévention réduira la probabilité de survenue mais aussi l’impact (en empêchant que l’ensemble du bâtiment soit détruit, et en limitant l’impact à une partie). L’incendie reste un cas particulier, pas forcément transposable en informatique, où on pourra plus facilement jouer sur la probabilité que sur l’impact."
#7.1
#8
J'ai souvenir d'une disquette d’une capacité de 1,44 Mo qui contenait un QNX, un (petit) OS complet, avec gestionnaire de fichier, un browser, du réseau, un terminal, et quelques bricoles.
On le trouve encore ici, et F. Bezies en parle là.
La mise en perspective est amusante
#8.1
N’empêche qu’elles marchaient du tonnerre (2 versions : une avec les pilotes de modem, l’autre avec les pilotes Ethernet que je dois toujours avoir dans une boîte qui prend la poussière).
Édit : typos, typos, typos.
Historique des modifications :
Posté le 17/06/2024 à 19h41
Et quand on regardait depuis Windows la place restante (la disquette devait être formatée en FAT donc Windows arrivait à la lire), il restait quelque-chose comme 3,2 Go d’après l’explorateur et non, je ne me suis pas trompé d’unité.
N’empêche qu’elles marchaient du tonnerre (2 versions : 1 avec les pilotes de modem, l’autre avec les pilotes Ethernet que je doit toujours avoir dans un boîte qui prends la poussière).
Posté le 17/06/2024 à 19h42
Et quand on regardait depuis Windows la place restante (la disquette devait être formatée en FAT donc Windows arrivait à la lire), il restait quelque-chose comme 3,2 Go d’après l’explorateur et non, je ne me suis pas trompé d’unité.
N’empêche qu’elles marchaient du tonnerre (2 versions : une avec les pilotes de modem, l’autre avec les pilotes Ethernet que je dois toujours avoir dans un boîte qui prends la poussière).
Posté le 17/06/2024 à 19h42
Et quand on regardait depuis Windows la place restante (la disquette devait être formatée en FAT donc Windows arrivait à la lire), il restait quelque-chose comme 3,2 Go d’après l’explorateur et non, je ne me suis pas trompé d’unité.
N’empêche qu’elles marchaient du tonnerre (2 versions : une avec les pilotes de modem, l’autre avec les pilotes Ethernet que je dois toujours avoir dans un boîte qui prend la poussière).
#9
Il y avait aussi beaucoup moins de prédateurs, moins d'enjeux, et moins de focus sur les questions de sécurité.
"à l'époque", les systèmes et les protocoles n'étaient pas pensé pour être sécurisés comme aujourd'hui. Tout était troué de partout mais ça avait moins d'importance.
Les systèmes d'hier étaient des maisons en bois et ceux d'aujourd'hui des châteaux forts, certainement plus complexes et plus couteux à sécuriser, mais faisant aussi face à des attaques plus fréquentes et d'un niveau incomparable.
Historique des modifications :
Posté le 18/06/2024 à 05h50
Je ne sais pas si la sécurité était vraiment meilleure ou plus facile "avant" juste parce que les systèmes étaient plus simples.
Il y avait aussi simplement beaucoup moins de prédateurs, et moins de focus sur les questions de sécurité.
"à l'époque", les systèmes et les protocoles n'étaient pas pensé pour être sécurisés comme aujourd'hui. Tout était troué de partout mais ça avait moins d'importance.
Les systèmes d'hier étaient des maisons en bois et ceux d'aujourd'hui des châteaux forts, certainement plus complexes et plus couteux à sécuriser, mais faisant aussi face à des attaques plus fréquentes et d'un niveau incomparable.
Posté le 18/06/2024 à 05h51
Je ne sais pas si la sécurité était vraiment meilleure ou plus facile "avant" juste parce que les systèmes étaient plus simples.
Il y avait aussi beaucoup moins de prédateurs, et moins de focus sur les questions de sécurité.
"à l'époque", les systèmes et les protocoles n'étaient pas pensé pour être sécurisés comme aujourd'hui. Tout était troué de partout mais ça avait moins d'importance.
Les systèmes d'hier étaient des maisons en bois et ceux d'aujourd'hui des châteaux forts, certainement plus complexes et plus couteux à sécuriser, mais faisant aussi face à des attaques plus fréquentes et d'un niveau incomparable.
#9.1
Un serveur physique, la surface d'attaque était plutôt délimitée (OS / middleware / appli).
Un container, tu as le serveur physique, l'OS de l'hyperviseur, la couche de virtualisation, l'OS de la VM, sa couche de virtualisation, ses API de containerisation, l'OS du container, les middlewares déployés dedans, les dépendances du code, les dépendances transitives, le code, les services d'exposition, etc.
Et oui, à l'époque c'était plus YOLO car moins de conscience sur ce sujet (même si y'a encore du chemin à faire). Le réseau ouvert par défaut et root / en mot de passe, c'était légion.
#10
Oublier la facilité de détection, c'est con. En gros, un truc qui arrive quasiment jamais mais indétectable se doit d'avoir une note de criticité élevée.